matkalkyl
dev

Denna sida är tillägnad utvecklingen av Matkalkyl.se. En ny version är fortfarande på gång. Du kan alltid komma till denna sida för den senaste informationen.

Projektet utvecklas och underhålls av Fredrik.

Nyhetsbrev

Jag har inte riktigt kommit i gång med regelbundna nyhetsbrev, men de kommer med tiden.

📬 Senaste: 2 Juni 2025

Till arkivet

Inblick

Referensmaterial för systemet

Referens över all programkod och mer

Projektverktyg

Jag har skapat ett enkelt projektverktyg för att bättre hålla reda på alla delprojekt. Vad du ser nedan är enbart en publik vy över innehållet i min projekt-hanterare. Där visas olika delprojekt samt hur mycket tid jag spenderat på respektive del. Jag har möjliget att lägga in kommentarer samt selektiv skärmdump som hamnar direkt här i form av bild. Systemet är helt integrerat med mina övriga verktyg och denna sida uppdateras därför automatiskt i realtid.

Dokumentation

Status: checkout idag
Mängd: 0h 57m totalt

dokumentation:

Avser processen att systematiskt dokumentera systemets egenskaper och specifika komponenter för framtida referens. Del av att vara en "vuxen programmerare". Dokumentation ska dock också tjäna syftet att vara en kreativ aktivitet i konceptuellt tänkande, annars är jag inte intresserad. Därför är det viktigt att verktygen för dokumentation är flexibla för att vara hängivna tankarnas rytm och inte bara en mekanisk process. Använder detta verktyg.

No comments yet.

Lager 1

Status: checkout idag
Mängd: 26h 27m totalt

lager 1:

Första direkta initiativet för att sätta ihop allt till en minimal fungerande version. Innefattar Databas, Websocket Node server, frontend Javascript, minimalt UI/UX. Det visar sig att strukturen jag planerade för databasen är mycket bra, samt att jag redan planerat och skapat grundläggande arkitekturen för Node servern. Servern i övrigt är också i tillräcklig ordning. Saknar fortfarande 50% eller mer av allt basalt som jag vill ha klart men får fixa det stegvis.


  • Tack vare #4315: Börja med högkvalitativ men icke överflödig dokumentation av befintlig kod då det börjar bli nödvändigt. Närminnets gränser är redan passerade.


  • Skapa minsta möjliga grafiska gränssnitt för fungerande version.


  • Första test-användaren i databasen är registrerad. Saker faller på plats.


  • Lager 1 - Databas, websocket front/backend, och API. Det mest grundläggande.

Skapa detta aktivitetsverktyg

Status: checkout idag
Mängd: 21h 28m totalt

  • Bugfix


  • Bugfix


  • Bugfix och UI-förbättring.


  • td [ ] auto-lägg-till [ ] syntax för kommentarer med td prefix.


  • td [ ] metod for att skriva in todo på projekt även om incheckad på annat projekt utan behöva check ut/in.

Visa alla

Doc

Status: checkout idag
Mängd: 12h 37m totalt

doc:

System, princip, disciplin och metod för hur dokumentera källkod och annat. Utan dokumentation är det svårt att förstå och underhålla programkod. Dokumentation är basal komponent i alla projekt men ofta dåligt implementerad med allt från obefintlig och förvirrande till onödigt expressiv och tidskrävande. Syftet här är att lägga grunden för en personlig tradition för dokumentation. Min personliga dokumentationsrutin har varit mycket knapphändig, men Linux är bästa miljön för att utveckla det, eftersom den som saknar struktur och personlig dokumentation straffas hårt via oväntade och självförvållade systemfel. Samma princip gäller dock inom programmering generellt sätt. Dokumentering tar lite mer tid men sparar mycket tid i längden. Den kloke förstår att dokumentation inte bara handlar om att beskriva saker, men att träna ens bedömmningsförmåga i att avgöra ett fenomen och kategorisera dess innehåll, vilket tränar förmågan och vanan att upprätthålla ett mer medvetet förhållningssätt till sin omgivning där ett fenomen förstås mer än det antas. Via ökad förstålese uppstår en högre grad av system-intuition för hur systemen kan utvecklas vidare. Dokumentation är därmed också ett sätt att träna upp perception (hur vi förstår världen) vilket gynnar tankeförmåga och handlingskraft.


  • Tog mer tid än planerat, men det blev bra och är en fundamental komponent som kommer bestå och fortsätta förbättras över tid. Systemet är halvautomatiskt och uppdateras i enlighet med min programkod.


  • Färdigt gränssnitt för referensmaterial som projektet generear och behövs för att kunna förstå, utveckla och underhålla systemet. Jag kunde inte integrera det i min terminal-miljö inom rimlig tid så jag gjorde ett WebUI istället. ChatGPT gjorde dock en Vim-key kompatibelt läge för mig i textarea-elementet (ytterst basalt men tillräckligt).


  • Hur har jag i skrivandets stund lyckats förlora 4 timmar på detta? Känns orimligt. Tidsuppfattningen har påverkats. Fälla med AI. Vissa problem kan den inte lösa, men skapar en känsla av att du nästan har lösningen och man försöker igen och igen men får bara mer problem. AI är bra för göra häst-jobb, att utvärdera referensmaterial, och för reflektion men inte för att förlita sig på. Behöver motverka detta beteende mönstret att fastna i AI.


  • Skapa en gammal hederlig Web-lösning som "fallback-lösning". Jag måste ha ett dok-system för källkod. Skapa ett WebUI för dokumentering som körs i webläsare paralellt. Dokumentation är ändå mer av konceptuellt tänkande och är inte beroende av hypereffektiva tangentbordskommandon, även om det är trevligt.


  • Avbryter det försöket att skapa 100% integrerad lösning. Jag saknar domänspecifik kunskap (Tree-sitter m.m) för att kompensera för AI's svårighet att lösa det. Jag löser det "fint" i framtiden i mån av tid och behov.

Visa alla

Holistiskt perspektiv

Status: checkout idag
Mängd: 0h 08m totalt

  • Med anledning av #c242 behöver jag metod för att inte förlora tidsuppfattning vid krävande arbete. Till skillnad från djupfokus som är produktivt och inte ska störas, så finns det andra typer av arbete som i vidare reflektion visar sig vara onödigt eller fruktlöst arbete, och som måste utvärderas och avbrytas under pågående arbete. Mät pågående arbete mot den aktuella tidsåtgången. Det är ett sätt att omvärdera processen och byta riktning om det behövs.

Async Mutex Pipes

Status: checkout idag
Mängd: 1h 42m totalt

async mutex pipes:

Egen modell för asynkron kommunikation in Javascript system. Ersätter det inbyggda event-systemet. Bygger på tidigare arbete. Visat sig vara mycket effektivt i praktiken.


  • Ordna en central dispatcher för signalhantering.


  • Signalbaserad kommunikation ska bara meddela att något hänt, inte skicka data, så att varje komponent själv hämtar sin information och förblir helt oberoende. Sändare bryr sig inte om mottagare. Mottagare ansvarar för att hämta data via publika gränssnitt. Data ska ej skickas via AMP. Leder till hårt kopplad och svår kod (erfarenhet, och AMP är menat att lösa det).

Logserver

Status: checkout 1 vecka sedan
Mängd: 3h 18m totalt

logserver:

Har ett internt loggsystem för all utveckling. Vilken komponent jag än utvecklar kan skicka diagnostik och loggar till ett centralt system. Att göra debug i nvim, javascript, databas, server, php, ajax, etc. är annars svårt. Att lägga tid på att installera, underhålla och lära sig separata konventionella system för varje enskilt område är inte alltid effektivt och tar mer tid i slutändan.


  • td [ ] Fixa nvim logsystem när server inte är tillgänglig (stannar).


  • Fungerar. Nvim (eller vad som helst) till lokal "pipe" -> lokal server läser pipe och skickar till central server -> central server vidarebefordrar till klienter som lyssnar på loggserver -> klienter ex webui, 🔗 tui, visar loggar i realtid.


  • Unix Domain Sockets är svårare än Websockets för att hantera hög-tryck och flera klienter på realtid-diagnostik-system. Ska återgå till tidigare fungerande lösning med websockets med webui för realtids-diagnostik. Kan göra CLI klient med interface mot websocket servern för integrering med lokala verktyg om befintligt webui inte är bekvämt nog.

GitHub logistik

Status: checkout 1 vecka sedan
Mängd: 7h 04m totalt

  • Återskapat git-historik

Organisera katalogstruktur

Status: created 3 veckor sedan
Mängd: 0h 00m totalt

  • td [ ] Behöver slutföra standardiseringen av ordningen för mina filer och kataloger som innefattar innehåll i alla avseenden, inte minst kod och konfigurationer. Etablera koncept test-filer, arkiv, projekt, dev, backup.

phxm

Status: created 3 veckor sedan
Mängd: 0h 00m totalt

  • td [ ] Php formatter för nvim inte installerad, eller fungerar inte.


  • td [ ] Möjlighet att binda projekt-specifika kommandon (ex make; make install...) för ett projekt till tab-index menyn till vänster (flash-bindings), ex nummer indexet, som öppnar och kör kommandot i en ctxterm Alternativt skapa ett nvim-plugin som läser från en UDS och uppdatterar bubblecol-flashbindings, varav fish kan skicka senaste kommandot till PhxM IDE.


  • td [ ] Öppna ctxterm cd till symlink include dir, och om flera, presentera möjlighet att välja. Då bättre öppna i phxm projekt baskatalog, och integrera symlink katalog-väljare i fish, för att inte kräva dialog varje gång ctxterm öppnas, då syftet är att snabbt åtkomma en terminal.


  • td [ ] Integration för hoppa till include-kataloger, (fish integration, men bättre i phxm och låta en ctxterm kvarvara i sin katalog). Kanske telescope filter-selector för befintliga ctxterms.

Lokal utvecklingsmiljö

Status: created 3 veckor sedan
Mängd: 0h 00m totalt

  • td [ ] Fish shell skriver ut info om det finns en fördefinierad info-fil i nuvarande katalog.


  • td [ ] vim.treesitter.language.require_language() is deprecated. Run ":checkhealth vim.deprecated" for more information

Metod för designval efter behov

Status: checkout 3 veckor sedan
Mängd: 1h 03m totalt

  • Mins att jag skapade 🔗 trm-workflow, vilket jag framgångsrikt använder nu (detta systematiska och flexibla självreflektionsverktyg som också strukturerar alla mina projekt och tillåter snabb kontext-byte utan fokusförlust). Dock behövs nu ett väldigt specifikt kognitivt verktyg för att eliminera risken att förlora tid genom att överarbeta ett givet system.


  • Skapa en ontologi för att bedöma ett systems komponenter och dess nödvändighet i relation till ett ändamål. En ontologi för det generella behovet har jag redan skapat 🔗 socm-ontology. Vad som behövs är ett specifikt kognitivt verktyg som med precision applicerar den ontologin på detta specifika problemområde: att bedöma vilka komponenter som ska ingå i ett datorsystem. Den generella ontologin svarar dock redan mot det behovet. Vad som behövs här är en konkret applicering av den ontologin.


  • Med anledning av #1c0c ska jag utveckla metod för att bättre undvika att gå i samma fälla igen där jag går från en "kan vara bra att ha" mentalitet till en "är absolut nödvändigt". Behöver någon sorts systematik för det samt diciplin att fökja det.

Brandvägg

Status: checkout 4 veckor sedan
Mängd: 4h 38m totalt

  • Har gjort för komplicerad design. För mig okänd detalj skapar negativ kedjereaktion som undgår min kunskap.


  • Brandväggen fungerar ej som tänkt. Regler appliceras inte som tänkt.


  • "Mjukat upp" brandväggen för att möta behov. Fixat bugg.


  • Ännu mer härdad brandvägg. Behöver dock systematisk genomgång framöver för säkerställning.


  • Justera övervägningsprocessen. Är ofta ett dilemma att antingen bygga egna lösningar eller gå på djupet med ett enskilt verktyg. Vad som är effektivast är inte alltid självklart. Tummregel är att lita på välkända verktyg och lägga tid på att lära sig dem. Det ger bättre avkastning på sikt även om kortsiktig förlust i den specifika avsikten, då kunskapen består och sannolikt gynnar i framtida ärenden (förutsatt att verktyget är "etablerad tradition"). Brandväggen jag använder har bra inbyggda verktyg som överlägset ersätter endel tidigare lösningar jag funderat på.

Visa alla

Lär mig Docker Compose

Status: checkout 4 veckor sedan
Mängd: 1h 04m totalt

doc:

System, princip, disciplin och metod för hur dokumentera källkod och annat. Utan dokumentation är det svårt att förstå och underhålla programkod. Dokumentation är basal komponent i alla projekt men ofta dåligt implementerad med allt från obefintlig och förvirrande till onödigt expressiv och tidskrävande. Syftet här är att lägga grunden för en personlig tradition för dokumentation. Min personliga dokumentationsrutin har varit mycket knapphändig, men Linux är bästa miljön för att utveckla det, eftersom den som saknar struktur och personlig dokumentation straffas hårt via oväntade och självförvållade systemfel. Samma princip gäller dock inom programmering generellt sätt. Dokumentering tar lite mer tid men sparar mycket tid i längden. Den kloke förstår att dokumentation inte bara handlar om att beskriva saker, men att träna ens bedömmningsförmåga i att avgöra ett fenomen och kategorisera dess innehåll, vilket tränar förmågan och vanan att upprätthålla ett mer medvetet förhållningssätt till sin omgivning där ett fenomen förstås mer än det antas. Via ökad förstålese uppstår en högre grad av system-intuition för hur systemen kan utvecklas vidare. Dokumentation är därmed också ett sätt att träna upp perception (hur vi förstår världen) vilket gynnar tankeförmåga och handlingskraft.


  • td [ ] Gör utvärdering på Docker, trade-offs etc. Docker förenklar installationer. Jag gillar inte när system är för enkla, för det betyder oftast lägre grad av kontroll inflytande, vilket i sig leder till värre komplexitet på sikt då de svarar dåligt mot ökade krav från närliggande system.


  • Saknar robust systematik för översikt och utvärdering av teknologier (ex Docker har jag ignorerat, Ansible har jag utvärderat). Att vara oinformerad kan leda till onödigt besvär.


  • Gör allt utan docker, men vissa saker är enklare att testa med docker. Är i dagens läge osäker på vart jag placerar Docker i min system-metodologi.

Server utvecklingsmiljö

Status: checkout 4 veckor sedan
Mängd: 0h 00m totalt

  • td [ ] Behöver göra terminal-gränssnittet på servern mer likställt med lokal konfiguration. Ex. ctrl + f/t för fzf funkar ej i fish.


Cred, färdigställ hela processen

Status: checkout 4 veckor sedan
Mängd: 0h 51m totalt

🔗 cred:

används för autentificiering och sedan upp/ned laddning av backup arkiv, kan automatiseras och integreras med det mesta.


  • Gjort samma misstag igen som 6/Jun. Hade viktig fil förlorad i migration av data. Git laddar ej upp test-filer som förväntat. Viktig fil i katalog för test-data. Återställt repo från Git. Därmed fil i test-katalog förlorad. Åter igen räddad av en annan gammal ad-hoc backup.


  • Raderade cred.vault av misstag vid organisering. Räddad av ad-hoc backup.

Överväg CDN

Status: checkout 1 månad sedan
Mängd: 2h 44m totalt

  • Ingen koll på brandväggs-loggar. Förslag: System för översikt. (FW har regler som skriver loggar).


  • Saknar unison strategi för hantering av blockerade ip (bottar etc). FW, Web, cron (?) lägger till adresser, med olika tidsspann.


  • Uppdaterat regler för brandvägg.


  • Migration från CloudFlare, förnya certifikat etc.


  • Skippar CloudFlare, onödig koplexitet som ger problem vars tidsåtgång inte motiverar fördelarna i dagens läge.

Visa alla

Mindre tekniska åtgärder

Status: checkout 1 månad sedan
Mängd: 2h 18m totalt

  • Glömmer make install innan jag testar uppdatering.


  • Bugfix i 🔗 permtermbuf.nvim. Tack GPT o3. "TL;DR: Du försökte köra en terminal i en buffer som inte var en riktig terminalbuffer. Nu låter du :terminal själv skapa buffern – och då fungerar det."

Processoptimering, TRM-workflow och SoCM-ontology

Status: checkout 1 månad sedan
Mängd: 1h 24m totalt

processoptimering:

Syftet är att optimera projektutvecklingsmodellen för utveckling av detta projekt (Matkalkyl).

🔗 socm-ontology:

Ursprungs-ontologin som meta-modellen TRM-workflow baseras på, vilket Matkalkyls projektutvecklingsmetod i sin tur baseras på. SoCM är en funktionell universiell ontologisk arkitektur som beskriver den generativa strukturen hos alla begreppsmodeller---inklusive sig själv, och är därmed också själv-reflexiv. Den är funktionell på så vis att den används för att systematisera människans strukturering av förståelse för att skapa uttömmande perceptuell klarhet av ett subjekt.

🔗 trm-workflow:

Syftet är också att öka graden av medvetande---med andra ord: meta-kognition; att tänka kring tänkandet---genom att återkommande klassificiera process-relaterad information---att identifiera relevanta intryck och dela in dem i kategorier. Ökar förmågan att se strukturer i processer.


  • Utökat !🔗 trm-workflow med kategorier för projekt-anteckningar. Ökad struktur.


  • Ser över hur kommentarer i projekt-korten (exempelvis denna) skrivs bättre för ökad precission och relevans.

Besluta mellan BlackBlaze och Storj

Status: checkout 1 månad sedan
Mängd: 0h 11m totalt

  • BlackBlaze eller Storj. Val är irrelevant – leverantör ska lätt kunna bytas ut. !🔗 cred stödjer båda eller se till det.

Agile och Scrum

Status: cancel 1 månad sedan
Mängd: 5h 45m totalt

  • Scrum är trademark och för snävt. Egen metod (TRM) bättre anpassad till mitt holistiska perspektiv. Agile har värde.


  • Undersök Agile och Scrum som möjliga metoder, anpassade till mina omständigheter. Syfte: hitta komplett lösning för utveckling.

Skapa process modell för mjukvaruutveckling

Status: finish 1 månad sedan
Mängd: 1h 21m totalt

  • !🔗 trm-workflow klar.


  • Skapa den rutin inom vilken all utveckling sker. Metod för att rikta insats, samt hålla koll på alla del-projekt.

Nyhetsbrev

Status: finish 1 månad sedan
Mängd: 5h 11m totalt

  • Skriver för Juni

Kuben

Den tredimensionella kuben ovanför kan uppfattas på olika sätt beroende på perspektiv och hur hjärnan tolkar djup och vinklar. Den optiska effekten uppstår eftersom kubens linjer och hörn kan tolkas på flera sätt, vilket gör att den verkar skifta form eller riktning.